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METHOD AMD SYSTEM FOR PROCESSING 
EI.ECTROMC PAYMENT TRANSACTIONS 



Field of the Invention 

The invention relates to systems and methods for processing electronic 
transactions, and more specifically^ to a system and method for receiving, processing 
and transmitting electronic payment transaction information. 

Background of the Invention 

Merchants typically accept various forms of payments from consumers 
in the course of engaging in the sale of goods and/or services. Some of these 
transactions include payments by cash, by check, debit card, credit card and the like. 

Many of these foims of payments are electronic in nature (e.g., credit 
card, debit card, electronic check payments, stored value cards, loyalty points 
redemptions, electronic benefits transfers) and afford certain conveniences to 
consumers. For example, when electronic payments are accepted, consumers do not 
have to determine whether they have a sufficient amount of cash on their person, they 
often do not have to transfer funds to the merchant immediately, and at times, can 
purchase goods or services utilizmg a line of credit. 

Such electronic payment offerings also benefits merchants. For 
example, by offering an array of payment options to consumers, merchants typically 
recognize an increase in sales. 

Nevertheless, present elwtronic payment systems have various 
drawbacks. For example, electronic payment systems that are Io<^6d at a merchant 
site can have limitations with respect to the type of terminals that can interact with 
such system. Typically, a merchant site has one or more central computers or servers 
that support electronic payment termmals that are used at the merchant. Only those 
terminals that are configured to interact with the merchant computer or server can be 
used. One solution is to have multiple servers or computers, but such a system can be 
expensive and cumbersome. 
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Another solution is continuously modify the server or computer as new 
terminals are desired to be used at the merchant site. Such a solution, however, can 
require significant maintenance of the merchant's computer software and hardware. 

In addition, electronic payment systems typically communicated via a 
5 dial-up modem. Such a system is inconvenient to consumers and merchants as 

transactions can take a long time to be completed, causing delay to the consumer and 
merchant In addition, such systems do not support certain encryption techniques 
which provides increased security to ttie data transmitted over the electronic payment 
system. Moreover, using a dial-up modero requires that a plurality of telephone lines 
10 be used if a merchant desires to support transactions using numerous electronic 
payment terminals. 

Also, many electronic terminals are configured such that trmisaction 
data relating to the settlement process is stored by such tenninals and only sent to the 
merchant server as a batch. Such an arrangement results in delay when the settlement 
15 process is effectuated. 

Snmroarv of the Invention 

The Invention relates to systems and methods for processing 
transactions, and more specifically to a system and method for receiving, processing 
2 0 and transmitting electronic payment transaction information which overcomes the 
above-mentioned disadvantages. The system and method accesses a transaction 
software engine fliat effectuates the authorization of electronic payment requests and 
the settlement of authorized electronic payments. The transaction software engine, in 
accordance with an embodiment of the invention, resides at a merchant's site and 

2 5 more specifically within the merchant's server or computer which is in 

communication witii one or more network terminals. With such a system, data 
respecting certain transactions (e.g., authorization, settlement, etc.) are sent by a 
terminal to the software engine. Typically, authorization requests are processed when 
the electronic payment request is made. Settlement requests, in accordance with an 

3 0 embodiment of the invention, are stored by the merchant's terminal until a 
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predetermined time, and then each of the requests are transmitted on a transaction-by- 
transaction basis from the engine to a data transaction host for processing. 

In addition, the software engine enables the transmission of data over 
tiie Internet. As a result, the amount of time to process payment authorization and 
5 settlement is reduced as compared witii the exclusive use of traditional telephone 
lines. 

Moreover, the transaction software engine is capable of accepting data 
of varying formats and re-encoding such data so that it may be processed by the 
transaction software engine. As a result, the transaction software engine can process 
1 0 data that is received from and sent to a variety of terminals as well as data that is sent 
to and received from a variety of data transaction providers host. 

Brief Description of the Drawings 

Further objects, features and advantages of the invention will become 
1 5 apparent fix)m the following detailed description taken in conjunction with the 

accompanying drawings showing illustrative embodiments of the invention, in which: 

Fig. 1 is a block diagram of an electronic payment transaction system, 
in accordance with an embodiment of the invention; 

Fig. 2 is a block diagram of an electronic payment transaction system, 
20 in accordance with another embodiment of the invention; 

Fig. 3 is a block diagram of modules incorporated within a transaction 
software engine that processes electronic payment transactions, m accordance with an 
embodiment of the invention; 

Fig. 4 illustrates data fields that are populated when processmg 
2 5 electronic payment transactions, in accordance with an embodiment of the Invention; 

Fig. 5 is a flowchart illustrating the method of authorizing an electronic 
payment request, in accordance with an embodiment of the invention; and 

Fig. 6 is a flowchart illustrating the method of settling electronic 
transactions, m accordance with an embodiment of the invention. 
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Detailed DescHp tion 

The invention relates to systems and methods for piwessing 
transactions, and more specifically to a system and method for receiving, processing 
and transmitting electronic paymait transaction information. The system and method 
5 accesses a transaction software engine that effectuates the authorization of electronic 
payment requests and the settlement of authorized electronic payments. The 
transaction software engine, in accordance with an embodiment of the invention, 
resides at a merchant's site and more specifically within the merchant's server or 
computer which is in communication with one or more network or serial terminals. 

1 0 With such a system, data respecting certain transactions (e.g., authorization, 

settlement, etc.) may be s«nt by a termmal to the software engine as each transaction 
occurs (as opposed to a group of transaction which are ^t in a batch). 

In addition, the software engine enables the transmission of data over 
the Internet. As a result, the amount of time to process payment authorization and 

1 5 settlement is reduced as compared with the exclusive use of traditional telephone 
lines. 

Moreover, the transaction software engine is capable of accepting data 
of varying formats and re-encoding such data so that it may be processed by the 
transaction software engine. As a result, the transaction software engine can process 
2 0 data that is received from and sent to a variety of terminals as well as data that is sent 
to and received from a variety of data transaction providers host 

The System 

Fig. 1 is a block diagram illustrating electronic payment transaction 

2 5 system 10 that incorporates features of the present invention. System 10, among other 

things, handles authorization of electronic payment transactions and settlement of 
such transactions by supporting communication between merchants, such as merchant 
100, and payment processors, such as data transaction provider 140. As shown in 
Fig. 1, various entities may be mvolved in such processmg. For example, system 10 

3 0 enables conmiunicatioij between merchant 1 00 and data transaction provider 140 
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through a public network, such as the Internet 120, and, for example, a third patty 
Memet Protocol Network (IPN) 130. In one embodiment, ffN 130 may be provided 
by Datawire Communication Network's Transaction Delivery Network. 

Merchant 100 is any individual or entity th^ makes a request for 
5 authorization and/or settlement of an electronic payment transaction. It should be 
noted that the term "payment" used herein may include a transaction involvmg the 
payment of funds or the credit of funds. Typically, merchant 100 has one or more 
credit/debit card processing terminals for processing electronic payment requests. For 
example, in Fig. 1, merchant 100 has several terminals 102-1 to 102-N which are in 
10 communication with merchant server 110. In Fig. 1, termmals 102-1 to 102-N are 

connected to merchant server 110 by a serial connection, and therefore these terminals 
are referred to as "serial terminals." An example of a serial terminal 102 is Verifone's 
TRANZ model number 380. 

When, for example, an electronic payment tiunsaction request is 
15 generated by, let's say, serial terminal 102-1, data packets are sent from termmal 102, 
via a serial connection, to merchant server 110. Merchant server 1 10 comprises at 
least the following components: a central processing tmit 1 12, transaction software 
engine 1 1 1 and Internet router 113. 

CPU 1 12 may be embodied as a smgle commercially available 
2 0 processor. Alternatively, in another embodiment, CPU 1 12 may be embodied as a 
number of such processors operating m parallel. 

Transaction software engine 1 11 is oj^able to store one or more 
instructions, discussed further below in conjunction with Figs. 3-6, which the CPU 
1 12 is operable to rettieve, interpret and execute. For example, engine 1 1 1 preferably 

2 5 stores processes for authorizing and settling electronic payments as described below. 

CPU 1 12 preferably includes a control unit, an arithmetic logic unit 
(ALU), and a CPU local memory storage device, such as, for example, a stackable 
cache or a plurality of registers, in a known manner. The control unit is operable to 
retrieve instructions from transaction software ei^e 111. The ALU is operable to 

3 0 perform a plurality of operations needed to carry out instmctions. The CPU local 
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memory storage device is operable to provide high-speed storage used for storing 
temporary results and control information. 

Internet router 1 13 connects merchant server 1 10 to totemet 120, and 
may be, for example, a D-Link Router Model DI 704. In addition, merchant server 
5 110 may also be connected to hosts 142-1 through 142-N via dial-up modem (not 
shown). Iq accordance with an embodiment of the invention, the communication 
between merchant server 110 and host 142 is, by default, attempted via Internet 1 10 
and IPN 130. Thus, in such case, dial-up modem communication between transaction 
merchant server 1 10 and host 142 is only used when communication cannot be 

1 0 established by private network 130. 

As discussed more fiilly below, data transaction provider hosts 142-1 
through 142-N are configured for, among other things, receiving a request to process 
electronic payment transactions, detennining the type of electronic payment 
transactions that are requested, authorizing or rejecting the electronic payment 

1 5 transactions, and settling the transactions. Data transaction provider hosts 142-1 
through 142-N is configured to process conventional credit card and debit card 
transactioiK, electronic checks, gift cards, and the like. 

Fig. 2 is a block diagram illustrating electronic payment transaction 
system 20 in accordance with an embodiment of the invention. Payment transaction 

2 0 system 20 is similar to system 10 - in that a merchant (e.g., merchant 101) 

communicates with host 142 of data transaction provider 140 - via Internet 120 and 
IPN 130 but system 20 provides for a Transmission Control Protocol/Intemet Protocol 
(TCP/IP) connection between the terminals and the mei-chant server. Thus, as 
illustrated by Fig. 2, system 20 supports communication between TCP terminals 103-1 

2 5 through 1 03-N and merchant server 11 0 via Ethernet switch 1 04. An example of TCP 
terminal 103 is the Omni 3750. Like merchant server 100 of system 10, merchant 
server 1 10 of system 20 comprises transaction software engine 1 1 1, CPU 1 12 and 
internet router 113. 
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The Transaction Software Engine 

Transaction software engine 11 1 is operable to store instructions for, 
among other things, atrthorizing and settling electronic payments as described below. 
TraiKaction software engine 111 is capable of providing such instructions by, in 
5 accordance with an embodiment of the invention, accessing one or more transaction 
modules instantiated by engine 111. Such modules are illustrated in Fig. 3 and 
include: work item mcKiule 302, packet resolver module 304, receiver module 306, 
sender module 308, format generator module 310, NBDot formatter module 312, 
DBDot formatter module 314, authorization handler module 316, settlement handler 
1 0 module 3 1 8, command handler module 320, IPN transporter module 322 and dial 
transporter module 324. These modules wiU now be described below with reference 
to Fig. 3. The process of authorizing and settlmg electronic payment transactions, by 
utilizmg modules 302 through 324 of engine 1 1 1, is described below with reference to 
Figs. 5 and 6. 

15 It should be noted that DBDot, tmUot and S VDot are data format 

types that comprise one or more data fields described below with reference to Fig. 4 
and processed by one or more of hosts 142-1 to 142-N. These data formats typically 
differ with respect to length and/or order of the data fields included by the respective 
format type and may, in some mstances, include additional information useful in 

2 0 authorization and settlement processing. 

Referring to Fig, 3, work item module 302 is responsible for 
temporarily storing data that is received by merchant server 110 from, for example, 
serial terminal 102, TCP tennmal 103 or host 142. The data is temporarily stored 
such that engine 1 11 can process the data by one or more of the other modules 

2 5 illustrated in Fig. 3. Work item module 302 is accessed each time terminal device 102 
or 103 establishes a communication session with transaction software engine 111. 
Thus, each time data is sent to engine 1 1 1, a work item is created by work item 
module 302 and, by accessing the other modules, enables the processing of such data. 

Packet reiver 302 determines the request type that is associated with 

30 the received data. Thus, packet resolver 302 determines whether the received data 
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relates to a request for payment authorization, settlement request or a command. 

It should be noted that the term "authorization" refers to approval by 
data transaction provider 140 to validate a transaction for a merchant 100 or 101. 
Such authorization uidicates, for example, the availability of a purchaser's credit limit 
5 at the time the authorization is requested or the validity of the consumer's account 
number. "Settlemenf ' refers to the process of exchanging financial data resulting 
from sales transactions, cash disbursements, or merchandise credits, which are 
ultim^ely billed to an account of purchaser making an electronic payment. A 
"command" is an instruction that controls transaction software engme 11 1, and may 

1 0 mclude the "stop" command which terminates one or more communications, a "start" 
command which restores data flow of system 10 or 20, "power off' which shuts down 
engme 111, "power on" which turns on engine 1 11, and the like. 

Receiver module 306 enables the processing of data that is received 
from transaction software engine 111, These devices include serial terminals 1 02- 

1 5 through 102-N, TCP terminals 103-1 through 103-N or hosts 142-1 through 142-N. 
Sender module 308, however, enables the processing of data that is received by 
transaction software engine 111, such as serial terminals 102- through 102-N, TCP 
terminals 103-1 tlirough 103-N or hosts 142-1 through 142-N. Handling incoming 
and outgomg information streams, by receiver module 306 and sender module 308, 

2 0 respectively, facilitates the implementation of maintenance and enhancements to 
engine 111. 

A built-m timer is incorporated mto modules 306 and 308, such that 
communications made by systems 10 or 20 may be terminated in the event of a 
communication failure. In accordance with one embodiment of the invention, the 

2 5 time is set to 60 seconds. 

Format generator 310 identifies the manner in which the received data 
should be formatted. The format that is designated for data received and processed by 
transaction software engine 1 11 is, m accordance with an embodiment of the 
mvention, dictated by the host 142 that is targeted for the transaction. Thus, format 

3 0 generator 310 determines which host 142 is designated to handle the transaction and 
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identifies the data format that is supported by such host 142. Determining which host 
142 is designated to handle the transaction is accomplished by reading the data stored 
in the header of a packet for the data format (e.g., NBDot, SVDot, etc.) and the target 
host designated to process such data format. Thus, in such a manner, when receiving 
5 data from terminal 1 02 or 1 03, engine 1 1 1 determmes whether the received data is m, 
for example, the DBDot, NBDot, SVDot or some other data fonnat type. Upon 
identifying the data fonnat of the received data, fonnat generator identifies the 
appropriate formatter to be accessed to process received data. Two examples of 
formatter modules illustrated in Fig. 3 are NBDot formatter module 3 12 and DBDot 
1 0 formatter module 314, although of course transaction software engine 1 1 1 may be 
provided with additional formatter modules such that additional data formats maybe 
supported by engine 111 as required by hosts 142-1 through 142-N. 

Formatter mc^ules 312 and 314 receive data, which is typically 
received in the form of packets in a stream, and parse such packets based on the 
1 5 packet's fields. A list of fields that, in accoidance with an embodiment of the 
invention, may be included in communicated data packets and used by formatter 
modules 312 and 314 are described below with reference to Fig. 4. 

Authorization handler module 316 is responsible for processing 
authorization requests. Authorization module handler 316 generates the packet header 
2 0 for data packets relating to authorization. Such header includes, among other things, 
identification mfonmation for identifymg the packet as canrying data for an 
authorization request. Jh addition, authorization handler module 3 16 delegates the 
authorization request data to the appropriate transporter. (See description of IPN 
transporter module 322 and dial transporter module 324 below.) 

2 5 Settlement handler module 3 1 8 is responsible for processing settlement 

requests. Settlement handler module 3 1 8 generates the packet header for data packets 
relating to settlement requests. Such header includes, among other things, 
identification information for identifying the packet as carrying data for a settlement 
request. In addition, settlement handler module 318 delegates the mithorization 

3 0 request data to the appropriate transporter. (See description of ffN transporter module 
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322 and dial transporter module 324 below.) 

Command handler module 320 processes data that is received &om a 
remote computer for controlling transaction software engine 1 1 L This module parses 
and executes commands that allow for the remote control of transaction software 
5 engine 111. Hius, if a mesrchant desire to issue a command to stop or start 

tRomction software enginelll from, for example, a remote computer, commands 
issued from such computers are detected and processed by handler 320 of engine 111. 

BPN transporter module 322 provides formatting for transmitting and 
receiving data packets over the Internet and dial transporter module 324 provides 
1 0 formatting for transmitting and receiving data packets using a dial-up modem. In 
accordance with an embodiment of the invention, the data format used is an XML- 
based packet format. 

NBDot Data Fields 

1 5 Fig. 4 illustrates fields that are incorporated in data packets that are 

handled by systems 10 and 20 to process authorization and settlement requests. When 
data packets are communicated among the various devices shown in Figs. 1 and 2, 
these fields either store information pertinent to the request or the field remains 
empty. In another embodunent of the invention, one or more fields may store null 

2 0 data (such as the number 0) rather than being empty, such that each field either stores 
pertinait data or null data. 

The fields incorporated in the data packets used by systems 10 and 20 
are as follows: merchant number field 402, terminal serial number field 404, message 
type identifier field 406, account number field 408, expiration date field 41 0, transck- 

25 2 data field 412, track- 1 data field 4 1 4, transaction amount field 416, transaction 
number 418, transaction date field 420, transaction time field 422 and error message 
field 424. 

Merchant number field 402 refers to a unique merchant number that is 
assigned by data transaction provider 140 for each merchant 100, 101 that has access 
30 to system 10, 20, respectively. Terminal serial number 404 refers to a unique terminal 
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number that is stored by each of terminals 102-1 through 102-N and 103-1 through 
103-N and is provided to engine 1 11 to indicate the source of a transmitted data 
packet each time a data packet is transmitted to engine 111. 

Message type identifier field 406 identifies the type of message that is 
5 being transmitted across system 10 or 20. Message type may include: authorization 
(i.e., a request for authorization &om. terminal 102 or 103 to engine 1 11, or from 
engine 1 1 1 to host 142), authorization response (i.e., an authorization response from 
host 142 to engine 111, or from engine 111 to terminal 102 or 103), settlement (i.e., a 
request for settlement from terminal 102 or 103 to engine 1 1 1, or from engine 1 11 to 
1 0 host 142), settlement response (i.e., an settlement response from host 142 to engine 
1 1 1), close session (i.e., a request to terminate a session), clo^ session response (i.e., 
a confinnation to a request for terminating a session). 

Account number field 408 refers to the identification numt«r of the 
account from which the fiinds are to be transferred to effectuate an electronic 
15 payment. Expiration date field 410 refers to the date in which tiie electronic payment 
card (e.g., credit card, debit card, gift card) is to expire. 

Track 1 field 412 and track 2 field 414 comprise information that is 
stored on the magnetic strip of user's credit card, debit card, gift card, etc. In 
accordance with an embodiment of the invention, track 1 field is 79 bytes and 
2 0 comprises the account number, expiration date, name and discretionary data. Track 2 
field 414, in accordance with an embodiment of the invention, is 40 bytes in length 
and includes the account number, expiration date and discretionary number associated 
with the user's <^d. 

Transaction amount field 416 refers to the amount of fiinds that are 

2 5 involved in the electronic payment for which an authorization or settlement request is 

made. Transaction number field 418 refers to a unique identifier that is used to 
identify each transaction processed by systems 10 and 20. 

Transaction date field 420 and transaction time field 422 refer to the 
date and time, respectively, upon which each electronic payment transaction was 

3 0 processed by systems 1 0 and 20. 
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Error message field 424 stores information containing one or more 
errornotifications which are communicated to merchant 100, 101 when one or more 
errors occur. In accordance with an embodiment of the invention, transaction 
software engine stores the error message in error message field 424 inside the same 
data packet that terminal 102 or 103 is expecting, and therefore the terminal can 
airtomaticaiiy display the received error message. 

Other format types - such as DBDot or SVDot -- may be used. DBDot 
and SVDot utilize many of the same data fields as described above with respect to 
NBDot. These data formats may differ with respect to length and/or order of the data 
fields included by the rrapective type and may, in some instances, include additional 
infiMmation usefiil in authorization and settlement processing. 

Authorization Requests 

When an electronic payment is effectuated, merchant 100 or 101 
typically inputs the pertinent transaction information relatmg to the purchase (e.g., 
merchant identification information, consumer identification information, consumer 
account information, payment type, transaction amount, date, time) into an electronic 
payment processing tenninal, such as serial terminal 102 or TCP/IP terminal 103. 
This may be accomplished by, for example, swiping a card that contains the consumer 
identification mformation, consumer account information and entering the transaction 
amount by a keypad situated on terminal 102 or 103. The remaining information may 
be genearated automatically by terminals 102 or 103. 

The inputted information is then entered thereby allowing merchant 
100 or 101 to make a request for authorizing the payment transaction. As described 
above, the authorization process enables approval by data transaction provider 140 to 
validate a transaction for a merchant 100 or 101 . This validation ensures, for 
example, the availability of a purchaser's credit limit at the time the authorization is 
requested, that Hie account data that is provided is valid, and the like. 

Fig. 5 is a flowchart which illustrates the process of performmg an 
authorization request, in accordance with an embodiment of the invention. Such 
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process is described with further reference to systems 10 and 20 of Figs. 1 and 2, 
respectively, and the software modules of Fig. 3. 

At step 505, work item module 302 of transaction software engine 111 
receives authorization data packets which includes data relating to a transaction that 
5 occurred at merchant 100 or 101 . The authorization data populates at least the 
foUowmg fields of the data packets: merchant number 402, terminal serial number 
404, message type identifier 406 (indicating that, in this instance, the message type 
relates to an authorization request), account number 408, expkation date 410, 
transaction amount 416, transaction number 418, transaction date 420 and transaction 
10 time 422. 

Next, at step 510, format generator module 310, analyzes the fermatted 
authorization packets to determine which of host 142-1 through 142-N is delegated to 
receive the authorization request. Upon determining the target host, format generator 
module 310 transmits the authorization data packets to the formatter that is a^ociated 

1 5 vrith the targe* host 142, such that the authorization data packets can be read and 
processed by the target host 142. Thus, the data packets are forwarded from the 
format generator module 3 10 to NBDot Formatter 3 12 or DBDot formatter 3 14 (or 
some other formatter instantiated by transaction software engme 1 U and associated 
with one or more of hosts 142-1 through 142-N). 

20 At step 515, formatter 312 or 3 14 (depending on the targeted host data 

formatting requirements) encodes the header of the received authorization data 
packets for transmission to the target host 142. In so doing, authorization handler 
module 316 chooses either DPN transporter module 322 (if the data packets are 
transmitted over a IPN 130) or dial transporter module 324 (if the data packets are 

2 5 transmitted over a dial-up modem). In accordance with an embodiment of the 

invention, the communication of data packets between engine 111 to host 142 is, by 
default, attempted via IPN 130. Thus, in such case, dial-up modem communication 
between transaction software engme 1 1 1 and host 142 is only used when 
communication cannot be established by private networic 130. Ih accordance with 

30 an embodiment of the mvention, the header is encoded into Extensible Markup 



- 13 - 



wo 2005/091814 



PCT/US2005/004738 



Language (XML) ~ a well knowa markup language which facilitates the interchange 
of structured data. In addition, the XIVIL formatted data packets are communicated 
between transaction software engine 111 and host 142 over the Mtemet 120 using, in 
accordance with an embodiment of the invention, the Secured Sockets Layer (SSL) 
5 protocol, SSL is a well know protocol that transmits communicatiorK over the 
Intemet in an encrypted form. SSL ensures that the mformation is sent, unchanged, 
and only to the host that is intended by merchant 1 00 or 101 . 

After transaction software engine 1 1 1 sends the authorization request 
to host 142 (at step 515), engine 1 1 1 then awaits a response from host 142. In 

1 0 accordance with an embodiment of the invention, the response is also in XML 

language. Upon receiving the response, at step 520, engine 111 decodes the response 
received from host 142 via DPN 130 and then forwards the response to terminal 102 or 
103 (step 525). The authorization response is typically in the form of transaction 
acceptance or rejection. Once the authorization response is received at terminal 102 

15 or 1 03 of merchant 100 or 1 01, respectively, such merchant is informed of the 
authorization response as provided by terminal 102 or 103 and the authorization 
request process is complete. 

It should be noted that the method for processing an authorization 
request for a serial temunal 102 versus a TCP termmal 103 are quite similar. With 

2 0 TCP terminal 103, however, connection and disconnection steps arte typically 
provided by system 20, When terminal 103 initially receives transaction data for 
transmission to software engme 111, terminal 103 opens a TCP/IP socket and 
connects to engine 111 using a configured BP address. Similarly, after the 
authorization request is processed, engine 111 sends a signal to close the connection 

2 5 between engine 1 1 1 and terminal 103 , 



Settlement Requeste 

Authorized transactions are then settled by systems 10 and 20. In 
accordance with an embodunent of the mvention, once a transaction is authorized, the 
3 0 data requh^d for settlement of such transaction is communicated to transaction 
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software engine 111. Engine 111 is configured to store the authorization data for 
transactions that occurred during a predetennined period - e.g., for a given day until 
midnight and when such predetermined period is met, engine 1 1 1 receives the 
settlement data from terminals 102 and 103 and then engine 1 1 land transmits to the 
5 data to host 142 on a transaction-by-transaction basis for the transactions that 

transpired for that period. Thus, each authorization request may be sent by engine 1 1 1 
to host 142 via Internet 120 and IPN 130 as its own request. This is so even though 
more than one of the transaction-by-transaction requests may be in transmission 
and/or processed by, for example, host 142 at a given time, 

10 As described above, the settlement process refers to the process of 

exchanging financial data resulting fi-om a sales transactions, cash disbursements, or 
merchandise credits, which are ultimately billed to an account of the purchaser 
making an electronic payment. 

Fig. 6 is a flowchart which illustrates the piwess of performmg a 

1 5 settlement request, in accordance with an embodiment of the mvention. Such process 
is described with further reference to systems 10 and 20 of Figs. 1 and 2, respectively, 
and the software modules of Fig. 3. 

At step 605, work item module 302 of transaction software engine 1 1 1 
receives settlement data packets which include data relatmg to a transaction that 

2 0 occurred at merchant 1 00 or 1 0 1 . The settlement data populates at least the following 
fields of the data packets for each transmission to be settled: merchant number 402, 
terminal serial number 404, message type identifier 406 (indicating that, m this 
mstance, the message type relates to a settlement request), account number 408, 
expiration date 410, transaction amount 416, transaction number 418, transaction date 

2 5 420 and transaction time 422. 

Next, at step 610, format generator module 310, analyzes the formatted 
settlement packets to determine which of host 142-1 through 142-N is delegated to 
receive the settlement request. Upon determining the target host, format generator 
module 310 transmits the settlement data packets to the formatter that is associated 

3 0 with the target host 142, such that the settlement data packets can be read and 



- 15 - 



wo 2005/091814 



PCT/US2(M)5/004738 



processed by the target host 142. Thus, the data packets are forwarded from the 
format generator module 3 1 0 to NBDot Formatter 3 12 or DBDot formatter 3 14 (or 
some otiier formatter stored by transaction software engine 111 and a^ciated wilh 
one or more of hosts 142-1 through 142-N). 
5 Next, at step 615, transaction software engine 1 U transmits a 

settlement initiation request to host 142 and, at step 620, engine 111 awaits to receive 
an initiation response back from host 142. 

Once such initiation handshake occurs, at step 625, transporter 322 or 
324 encodes the header of the received settlement data packets for transmission to the 

1 0 target host 1 42. hi so doing, settlement handler module 3 1 8 chooses either IPN 
transporter module 322 (if the data packets are transmitted over IPN 130) or dial 
transporter module 324 (if the data packets are transmitted over a dial-up modem). In 
accordance with an embodunent of the invention, the communication of data packets 
between engine 1 U to host 142 is, by defiiult, attempted via IPN 130, Thus, in such 

1 5 case, dial-up modem communication between transaction software engine 1 1 1 and 
host 142 is only used when communication cannot be established by private network 
130. 

In accordance with an embodiment of the invention, the header is 
encoded into XML. In addition, the XML formatted data packets are communicated 
2 0 between transaction software engine 1 1 1 and host 142 over the Internet 120 using, in 
accordance with an embodiment of the invention, the SSL protocol to ensure that the 
mformation is sent, unchanged, and only to the host that is intended by merchant 100 
or 101. 

After transaction software engine 1 1 1 sends the settlement request to 

2 5 host 142 (at step 625), engme 1 1 1 then awaits a response from host 142 via IPN 130. 
In accordance with an embodiment of the invention, the response is also in XML 
language. Upon receiving the response, at step 630, engine 111 then sends a packet 
header response to terminal 102 or 103 (step 635) requesting the settlement 
information (described above) which is sent to host 142. Tramaction software engine 

30 111 then receives the setUeraent detail from terminal 102 and 103 (step 640). The 
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settlement detail is then encoded at the instruction of format generator module 310 
and sent to the targeted host 142 (step 645). Once the complete batch of settlement 
data is received and processed by host 142, engine 1 1 1 receives a settlement packet 
trailer indicating the end of settlement data packets (step 650). This trailer is then 
5 forwarded by engine 1 1 1 to terminal 102 or 103 (step 655) and then a settlement 
session termination request is sent to host 142 (step 660) indicating the end of the 
settlement process. 

It should be noted that the method for processing a settlement request 
for a serial terminal 102 versus a TCP terminal 103 are quite similar. With TCP 
1 0 terminal 103, however, connection and disconnection steps arte typically provided by 
system 20. Thus, when terminal 103 initially receives transaction data for 
transmission to transaction software engine 111, terminal 103 opens a TCP/IP socket 
and connects to engine 1 1 1 using a configured IP address. Similarly, after the 
settlement request is processed, engine 1 1 1 sends a signal to close the connection 
1 5 between engine 111 and terminal 103. 

The foregoing merely Illustrates the principles of the invention. It will 
thus be ^preciated that those skilled in the art will be able to devise numerous other 
arrangements which embody the principles of the invention and are thus within its 
spirit and scope. 

2 0 For example, although the electronic payment processing terminals 

described herein are the Tranz 380 and Omni 3750, other types of terminals may be 
\tsed. In addition the connections of these devices to merchant server 110 may be, m 
addition to an Ethernet or TCP/IP connection, a WI-H hub with USB connectivity, a 
wireless connection, or the like. 
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Claims 

1 . A method for pnx^ssing an electronic payment transaction, 
comprising: 

receiving a request for processing the electronic payment transaction 
5 from a payment terminal, the request including a format type; 

determining the format type of the request; 
identifying a host computer configured to process the determined 
format type; and 

transmitting the requ^t to the identified host computer. 

10 

2. The method of claim 1 further comprising: 

receiving a notification from the identified host indicating whether the 
request is approved. 

15 3. The method of claim 1 fiirther comprising: 

receiving a notification from the identified host indicating whether the 

request contains an error message. 

4. The method of claim 2 fiirther comprising: 

2 0 sending the notification to the payment tennmal. 

5. The method of claim 3 further comprising: 
sending the notification to the payment terminal. 

25 6. The method of claim 1, wherein the request comprises data packets 

having header information. 

7. The method of claim 6, fiirther comprising encoding iJie header 
information to enable communication of the request between the payment terminal 
30 and the host computer. 
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8, The method of claim 7, wherein the header information is encxjded 
using an Extensible Maricup Language. 

9, The method of claim 1, wherein the request for processing the 
5 electronic pajonent transaction relates to authorizing the transaction, 

10, The method of claim 1, wherein the request for processing the 
electronic payment h-ansaction relates to settling the transaction. 

10 11. A method for settling a plurality of electronic payments, comprising: 

requesting JSrora a terminal information relatmg to settlement of the 
plurality of electronic payments; 

receiving at least one respective data packet having settlement 
information for each payment of said plurality of electronic payments; 

1 5 _ determining the format type of each respective data packet; 

identifying a host computer configured to process the determined 
format type of each respective data packet; and 

transmitting each respective data packet to the identified host 
computer, wherein the identified host computer is configured to process the format 
2 0 type of said each respective data packet. 

12. The method of claim 1 1 forther comprbing: 

receiving a notification fi-om the identified host indicating whether the 
^ttlement is processed. 

25 13. The method of claim 1 1 further comprising: 

receiving a notification fi-om the identified host indicating whether the 
settlement generates an error message. 
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14. The method of claim 12 further comprising: 
sendmg the notification to the payment terminal. 

15. The method of claim 13 fiirther comprising: 

5 sending the notification to the payment terminal. 

1 6. The method of claim 1 1 wherein the request comprises data packets 
having header information. 

^ ° 17. The method of claim 16, fiirther comprising encoding the header 

information to enable communication of the request between the payment terminal 
and the host computer. 

18. The method of clarni 17 wherein the header mformation is encoded 
1 5 using an Extensible Markup Language. 

1 9. A system for processing an electronic payment transaction, comprising: 
an interface for receiving a request for processing the electronic 

payment transaction from a payment terminal, the request including a format type; and 
20 a processor for: 

determinmg the format type of the request; 

identifying a host computer configured to process the 
determined format type; and 

transmitting the request to the identified host computer. 

25 

20. The system of claim 19 wherein the processor is fiirther configured for 
receiving a notification firom the identified host mdicating wh^er the request is 
approved. 
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21. The system of claim 19, wherein the interfece is further configjured for 
receiving a notification &om the identified host indicating whether the requ^t 
contains an error message. 

5 22. The system of claim 20, wherein the processor is further configured for 

sending the notification to the payment terminal. 

23. The system of claim 21, wherein the processor is further configured for 
sending the notification to the payment temunal, 

10 

24. The system of claim 19, wherein the request comprise data packets 
having header information. 

25. The system of claim 24, wherein the processor is fiirther configured for 
1 5 encoding the header information to enable communication of the request between the 

payment terminal and the host computer. 

26. The system of claim 25 wherein, the header mformation is encoded 
using an Extensible Markup Language. 

20 

27. The system of claim 1 9, wherem the request for processing the 
electronic payment transaction relates to authorizing the transaction. 

28. The system of claim 1 9, wherein the request for processing the 
2 5 electronic payment transaction relates to settling the transaction. 

29. A system for settling a plurality of electronic payments, comprising: 
an interface for receiving at least one respective data packet having 

settlement mformation for each payment of said plurality of electronic payments; and 

30 a processor for; 
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determining the format type of each respective data packet; 

identifying a host computer configured to process the 
determined format type of each respective data packet; and 

transmitting each respective data packet to the identified host 
5 computer, vt'herein the identified host computer is configured to process the format 
type of said each respective data packet. 

30. The system of claim 29 wherein the inter&ce is further configured for 
receiving a notification fi-om the identified host indicatmg whether the settlement is 
processed. 

10 

3 1 . The system of claim 29 wherein the mterface is fiirther configured for 
receiving a notification fi-om the identified host indicating whether the settlement 

generates an error message. 

1 5 32, The system of claim 30 wherein the processor is further configured for 

sending the notification to the payment terminal. 

33. The system of claim 3 1 wherein the processor is fiirther configured for 
sending the notification to the payment terminal. 

20 

34. The system of claim 29 wherein the request compri^s data packets 

having header information. 

35. The system of claim 34 wherein the processor is further configured for 
2 5 encoding tiie header information to enable communication of the request between the 

payment terminal and the host computer. 

36. The system of claim 35 wherein the header information is encoded 
using an Extensible Markup Language. 

30 
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37. The system of claim 29 wherein the request for processing the 
electronic payment transaction is received from the payment terminal by a serial 
connection. 

5 38. The system of claim 29 wherein the request for processing the 

electronic payment transaction is received from the payment terminal by a an Internet 
protocol connection, 

3 9. The system of claim 3 8 wherein the Internet protocol connection 

1 0 comprises a TCP/IP connection. 

40. The system of claim 19, wherein the processor transmits the request to 
the host computer over the Internet. 



15 41 . The system of claim 19, wherein the processor transmits the request to 

the host computer by modem. 



wo 2005/091814 



PCT/US2005/(M)4738 




wo 2005/091814 



PCT/US2005/004738 



Transaction Software 



Work Item 
Module 



Packet 
Resolver 



Fomat 
Operator 



NbDot 
Fonnatter 



310 



DbDot 
Fonnatter 

314 



Audiorizadon 
Handler 



316 



Settlement 
Handler 



318 



Command 
Handler 



320 



Transporter 



Dial 

Transporter 
324 



Fig. 3 



2/5 



wo 2005/091814 



PCT/US2005/004738 



Merchant 


Tenninal 


Message 


Account 


Expiration 


Track-2 


Nuiriber 


Serial 


Type 


Number 


Date 


Data 




Number 


Identifier 








402 


404 


406 


408 


410 


412 


Track-1 


Transactioa 


Tiaosaction 


TYansaction 


Transaction 


Error 




Amount 


Nunber 


Date 


Time 


Message 


414 


416 


41S 


420 


422 


424 



Fig. 4 



wo 2005/091814 



PCT/US2OO5/004738 



BjBceive Formatted Autfaocization Packet From 



Analyze Fonnafted Autborizatioii Packet To Deteimiae y/'^ ' 
Host 



Encode Authorization Header For And Ttansmit To 
IPNHost 



Receive And DcKrode Response Ftom Host Via IPN 



Stand Aafliorization Packet To T« 



Fig, 5 



4/5 



wo 2005/091814 



PCT/US2005/004738 



Receive Poimatted Setttem^it Packet 



Aiialyzc Foimatted Setflemeat Packet To Detennine 
Host 



X 



I^ransmit Settlement bdtiation Request To IPN Host 



^615 



Receive Settlemeffit faitiation Refuse From IPN Host 



31 



Encode SettlemesDt Header And Tlansmit to IPN Host ^^^25 



IE 



Receive And Decode Rraponse From Host Via IPN ^^^30 



Sead Settlement Header Response To Terniinal 



Receive Settletnent Detail From Tenninal 



EiKode Settlemmt Detail And Send To Host Via IPN 



Receivie Settlemejit Trailer From Host 



SeadSottlem«it Trailer To Tenninai 



^655 





Seod Settlemoit Session Tmnina 


tion Request To Host 


^660 


Fig. 6 


Via IPN 







5/5 



INTERNATIONAL SEARCH REPORT 



International application No. 
PCrAJS05/04738 



CLASSIFICATION OF SUBJECT MATTER 
:: G06Q 40/00(2006.01) 



USPC: 705/40 
According to International Patent Clas 



>n (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Documentation searched other than minimuni documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 



DOCUMENTS CONSIDERED TO BE RELEVANT 



n of document, with indication, where appropriate, of the relevant pasages 



Relevant to claim No. 



US 7,006,993 B I (CHEONG el al.) 28 February 2006 (28.02.2006), see columns 6-7, line 24; 
sec column 15, lints 19-32; see figures. 2-3. 

US 6,609, 1 1 3 Bl (CLEARY et al.) 1 9 August 2003 (19,08.2003), see entire document. 



□ 



Further docunjents are listed in Uie continuation of Box C. 



□ 



Special catesoriei af ciled 
men) derining the setenl state < 



ot «oiuidered to be of 



ni which may throw doidtti on priodiy daimts) or whkh is cilcd to 



ng dole but laurthaa die "A" 



documem of paniciitar relevancti die claimed InvEntien ca 



specirnd) 

document refeninis to an ora) disclasitfc, i£ 
document published prior to ibt interutiu 



Ed invention csuiaot be 



being obnous to a person skiiied in the : 
documnd menriier of the sme patent fai 



Date of the actual completion of the international st 
22 June 2006 (22.06.2006) 



Date of mailing of the international search repo?t 

28 AUG 2006 



Name and mailing address of the ISA/US 
.Mail Stop PCT. Attn: ISAAJS 



P.O. Box 1450 

Alexandria. Virgitiia 223 1 J-S4S0 
Facsimile No. (571 ) 273-3201 



Tcleirfione No. (571 ) 272-5250 



Form PCT/ISA/2 10 (second sheet) (April 2005) 



From the 

INTERNATIONAL SEARCHING AUmORTrY 
To: 

BRAJ^DON N. SKLAR 
KAYE SCHOLER LLP 
425 PARK AVENUE 
NEW YORK, NY 10022-3598 



WRITTEN OPINION OF 
INTERNATIONAL SEARCHING AUlHOl 

(PCT Rule 42bis.\) 




28 AUG 200G 



Applicant's or agent's file reference 
23122-1504 



FOR FURTHER ACTION 

See paragraph 2 below 



International applici 
PCT/US05/04738 



International filing date (day/month^ear) 
15 Pefa-iaiy 2005 (15.Q2.2005) 



Priority date {day/moiUb/year) 
12 March 2004 (12.03.2004) 



International Patent aassiiication (IPC) or both national classification and IPC 

USPC: 



G06H4C 

705/40 



Applicant 

FIRST DATA CORPORATION 



I , This opinion contains indications relating to the following items: 

Basis of the opinion 
Priority 

Non-establishment of opinion with regard to novelty, inventive step and industrial applicability 

Lack of unity of inventioti 

Reasoned statement under Rule 43iw.l(a)(i) with regard to novelty, inventive step or industrial 
applicability; citations and explanations supporting such st 

Certain documents cited 

Certain defects in the international application 

Certain 



1X1 

□ 


Box No. I 
BoxNail 


□ 


Box No. Ill 


□ 


Box No. IV 




Box No. V 


□ 


Box No. VI 


□ 


Box No. VII 


□ 


BoxNo. Vm 



2. FURTHER ACTION 

If a demand for international preliminary examination is made, this opinion will be considered to be a written opinion of the 
international Preliminary Examining Authority ("IPEA") except that this does not apply where the applicant chooses an 
Authority other than this one to be the IPEA and the chosen IPEA has notified the Intemational Bureau under Rule ii6.\bis(b) 
that written opinions of this Intemational Searching Authority will not bs so considered. 

If this opinion is, as provided above, considered to be a written opinion of the IPEA, the ^plioant is invited to submit to the 
IPEA a written reply together, where appropriate, with amendments, before flie expiration of 3 months from the date of mailing 
of Form PCT/B A/220 or before the expiration of 22 mon^ from the priority date, whichever expires later. 
For further options, see Form PCT/IS A/220. 

3. For further details, see notes to Form PCT/ISA/220. 



Name and mailing address of the ISA/ US 
Mai Stop PCT, Attn: KAAJS 
Cwnmissioner for Patente 
P.O. Box 1450 

■ Alexandra, Virginia 223 \ 3-1 450 
Facsimile No. (571)273-3201 



Date of completion of this opinion 
22 June 2006 (22.06.2006) 



Vincent Millin 
TelcphOTieNo. (571)272-5250 



Fom PCT/ISA/237 (cover sheet) (April 2005) 



WRITTEN OPINION OF THE 
INTERNATIONAL SEARCHING AUTHORITY 



International application No. 
PCT/US05/0473S 



Box No. I Basis of this opinion 



1 . With regard to the language, this opinicm has been established on the basis of; 
El the international application in the language in which it was filed 

O a translation of the inteniatiojial application into , which is the language of a translation furnished for the pwposes of 

international search (Rules 12.3(a) and 23.1Cb)). 

2. With regard to any nucleotide andl/or amino add sequence disclosed in the international application and necessary to the claimed 
invention, this opinicm has been established on the basis of: 

a. type of material 

I I a sequence listing 

n tab]e{s) related to the sequence listing 

b. format of material 
i I on paper 

n in electronic form 

c. time of filing/furnishing 

I I contained in the international application as filed. 
□ 

filed together with the international application in electronic form, 
furnished subsequently to this Authority for the purposes of search. 



3. LJ addition, iii the case that more than one version or copy of a sequence listing and/or tablc(s) relating thereto has been filed 

or fUmished, &s required statemenis that the information in the subsequent or additional copies is identical to that in the 
application as filed or does not go beyond the application as filed, as appropriate, vrere fliniished. 

4. Additional comments: 



Form PCX'rSA/237(Box No. I) (April 2005) 



WRITTEN OPINION OF THE 
INTERNATIONAL SEARCHING AUTHORITY 



Box No. V Reasoned statement UDder Ru!e 43 bis.l(a)(i) with regard to novelty, inventive step or indnstrial 
applicability; citations and explanations supporting such statennent 



Novelty (N) 
Inventive step (IS) 
industrial applicability (lA) 



_YES 
_NO 



_YES 
_N0 



Claims NONE 



_NO 



2. Citations and explanations: 

Claims 1-41 lack novelty under PCT Article 33(3) as being unpatentable over Cheong et al. 

Re claims 1,11,19, and 29, Cheong teaches a method for processing an electronic payment transaction (col. 1, lines 40-63; abstract), 
comprising: receiving a request for processing the electronic payment transaction fronj a payment terminal (col. 1 5, lines 1 9-32), the 
request including a format type: identilying a host gomputer confined to process the determined format type (col. 6, tines 19-39; figs. 
2-3); and transmitting the request to the identified host computw (ool. 6, line 63 to col. 7, line 24). Cheong discloses electronic 
commerce transaction enables a vsw to shop at online merchant sites. The surrogate system provides controls ttot include monitoring 
the data streams and controlling the information flow between the user and the meichant sites. 



Re claims 2-5, 12-15, 20-23, and 30-33, Cheong teaches receiving a notification from the identified host indicating whether the request 
is approved (col. 17, lines 4-39). Cheong discloses email notification about any particular requests. 

Re claims 6-10, 16-18, 24-2S, and 34-41, Cheong teaches data packeb having header infoimation (col. 24, lines 25-55; fig. 47). In other 
words, Cheong discloses header for navigation. 



Form PCT/ISA/237 (Box No. V) (April 2005) 



